========================================================================= INFO-ATARI16 Digest Mon, 22 Jan 90 Volume 90 : Issue 83 Today's Topics: Bob Dobbs character set?? dissassembly (2 msgs) GNU/Sozobon C question Hello Questions! (FTP'ing from VAX) Spectre 2.5 Newsletter advisory ST S/ware Rental Places TURBO-C Question! ---------------------------------------------------------------------- Date: 23 Jan 90 01:55:48 GMT From: pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!ap lcen!jhunix!rick@tut.cis.ohio-state.edu (Eric Ruck) Subject: Bob Dobbs character set?? Message-ID: <4031@jhunix.HCF.JHU.EDU> I don't know about this Bob character, but I do seem to recall that either one or both of the Tramiels were Auschwitz survivors, hence the Hebrew. Eric ------------------------------ Date: 22 Jan 90 15:53:34 GMT From: sgi!shinobu!odin!odin.corp.sgi.com!portuesi@ucbvax.Berkeley.EDU (Michael Portuesi) Subject: dissassembly Message-ID: >>>>> On 16 Jan 90 02:58:17 GMT, kbad@atari.UUCP (Ken Badertscher) said: ken> Believe me, Arion, it's very very tempting at times. Especially when ken> you see some of the really silly things that some developers do to ken> break the rules. You want to punish them. But in fact, the end users ken> are punished worse if Atari breaks programs which break the rules. I disagree. In the end, the users are punished worse if Atari *doesn't* break programs which break the rules. Those programs keep Atari from adding bug fixes and enhancements to their operating system, which hurts everyone in the end -- not just those people who depend on broken software. ken> All ken> a user knows is that his favorite program doesn't work any more. If ken> the company that made it is no longer in business, that user is really ken> up the creek. True. But in many cases, the user may be able to switch to an alternative which didn't break the rules. And if I had some very important piece of software I depended on for my livelihood, I would think long and hard about migrating to something else if the company that produced it went out of business. --M -- __ \/ Michael Portuesi Silicon Graphics Computer Systems, Inc. portuesi@SGI.COM Entry Systems Division -- Engineering ------------------------------ Date: 22 Jan 90 18:02:02 GMT From: per2!dag@speedy.wisc.edu (Daniel A. Glasser) Subject: dissassembly Message-ID: <893@per2.UUCP> Being the person who wrote most of the MWC examples (other than most of the GEM examples, which were mostly written by a non-programmer), I would like to defend the MWC manual/examples a little here. In article <1540@cs.rit.edu>, ajy2208%ritcv@cs.rit.edu writes: > In article <10665@stag.math.lsa.umich.edu> hyc@math.lsa.umich.edu (Howard Chu) writes: > [...informative stuff deleted...] > >As for the stray data at the top, perhaps you're not aligning the > >screen memory correctly? > This was a problem at first, as I am a beginning ST programmer and > am not a registered developer (yet.. :-). Of course, the people > who wrote the MWC documentation didn't bother mentioning the > fact that the memory has to be ALIGNED.. But they provided a nice > example, in which they aligned the memory, so that's how I learned.. Sorry about that... The decision to not put the restriction into the main part of the documentation was made because it was unclear what future products might offer. There was supposed to be a note that stated that the current 520 and 1040ST machines had this restriction, but this got left out by accident, and nobody seems to have noticed. The examples had most of their comments stripped out so they could fit into the manual. > >If you're writing code that you eventually hope for > >other people to use, don't hard-code magic numbers like 32K into your > >screen manipulation routines. [In fact, don't even use 32K. You only > >need, at most, 32256, to get 32000 bytes on a 256 byte boundary, eh?] > Kind of interesting, that the example in the MWC manual does have > 32K hard wired in. Of course, it's only an example, but for someone > learning how to do something for a first time, it's not setting a > GOOD example.. sigh.. (at least it does have LOTS of examples).. Well -- I had to use some value when I wrote the example. I could have used a #define, but at the time it seemed like this would remain unchanged for the immediate future, and we didn't want to go through all the extra trouble (in the example) to calculate the memory needs of the new display. (It was not a GEM example, and S.A.L.A.D. was not yet written, and even when these two conditions are met, it is still more than a few lines of code to figure this out in the general case for all possible future display modes, if its possible at all. I don't know what happens when you use a Moniterm.) These examples were supposed to be short and illustrate proper use of the documented routine/function/feature, without adding lots of extra stuff that might confuse or intimidate the novice ST programmer. I might add that for a program like a picture viewer (as described in the original posting) to work with the overscan modification a simple file read / physbase change will not do the trick anyway. Most of these bitmap graphics file formats assume the standard ST screen layout. The fact is that at the time the MWC manual was written, there was very little programming documentation available for the ST. We went above and beyond the required material for just using our compiler and set a standard for completness which far outstripped anything available to the general public at the time, and which the competition took a long time to catch up with. We did not just rehash the material in the developers documentation, we wrote new documentation and provided examples for just about every Atari specific function in the system. We gave notes on how some BIOS/XBIOS/GEMDOS functions were documented to work in the developers documentation but actually worked in some other way and warned that these things may change. We went out of our way not to use any non-sanctioned hooks into the OS to make our product work. In my honest opinion, biased as it may be, the MWC manual is the single best volume for programming the ST published to date. It needs revision, bugfixing, and maybe some other tweeking (new GEM examples, etc.) and the compiler should be updated, but it is still a very good package at a good price. I don't work for MWC anymore, and don't speak for them. I've just seen a few people bash the MWC package recently and wanted to set the record a little straighter. I know that the posting to which I've followed up is not a bash, but it was a convenient place to put this. Daniel A. Glasser -- _____________________________________________________________________________ Daniel A. Glasser "Their brains were small and they died." uwvax.cs.wisc.edu!per2.uucp!dag ---Persoft, Inc.---------465 Science Drive-------Madison, WI 53711----------- ------------------------------ Date: 22 Jan 90 18:27:48 GMT From: per2!dag@speedy.wisc.edu (Daniel A. Glasser) Subject: GNU/Sozobon C question Message-ID: <894@per2.UUCP> In article <1990Jan17.154602.19880@chinet.chi.il.us>, saj@chinet.chi.il.us (Stephen Jacobs) writes: > 2)I like Mark Williams C. The non machine-specific parts are pretty K&R > compliant. The library is very UNIX-like. The support people are great if > you phone (don't write--they answer in 3 months). The compiler is said to be > derived from pcc. The source and machine language debuggers work well. > Steve J. The MWC compiler is not derived from PCC. It is derived from the Coherent (A 7th-edition Unix compatible OS with NO unix source code involved) compiler which had been ported from the PDP-11 to the 8086 and Z8001 before the 68000 port was done. The compiler base is similar to pcc in many respects, but it is not a derivitive of that compiler. A large part of the speed "problems" that the MWC compiler has is because of this history. A version (built from the same sources) ran on a PDP-11 as a cross compiler until version 3. The PDP-11 has only 64k of virtual address space. The compiler, therefore, uses disk files to store intermediate code and chains between programs to do various stages of compilation. The advantage to this is that the MWC compiler can run effectively in systems with limited memory (512k with DAs loaded) and can handle programs larger than available memory. I've linked an 800k program on a 520 with MWC. Daniel A. Glasser -- _____________________________________________________________________________ Daniel A. Glasser "Their brains were small and they died." uwvax.cs.wisc.edu!per2.uucp!dag ---Persoft, Inc.---------465 Science Drive-------Madison, WI 53711----------- ------------------------------ Date: 23 Jan 90 00:53:46 GMT From: zephyr.ens.tek.com!orca.wv.tek.com!pogo!bluneski@beaver.cs.washington.edu (Bob Luneski) Subject: Hello Message-ID: <8429@pogo.WV.TEK.COM> Hello Everyone!! I just wanted people to know that I just gained access to the network and can be reached here for questions and comments on Diamond Back. Thanks, Bob Luneski Author: Diamond Back ------------------------------ Date: 22 Jan 90 16:09:15 GMT From: ucsdhub!hp-sdd!ncr-sd!ncrlnk!ncrwic!wsucsa!mwjester@ucsd.edu Subject: Questions! (FTP'ing from VAX) Message-ID: <11456@wsucsa.uucp> In article <9001220804.AA20499@ucbvax.Berkeley.EDU>, FRACHEL@UMIAMI.MIAMI.EDU writes:> > I have a question about FTP'ing. It seems that I cannot login to most > so called 'anonymous' ftp sites while using the VAX system, but my > friend on a unix system can get in fine. > > Is there anything I can do about this? I can't answer your question about UUCP, but I can speak from experience about FTP'ing from a VAX/VMS system. Your system is converting everything to upper- case (I dunno why it was set up that way), and the system you are trying to connect to is case-sensitive (probably a Unix(TM) system). What works for me is to put quotation marks around anything the remote system is going to see. e.g. FTP some.site.name status message from the FTP program here...it should eventually tell you it connected, and give you the prompt. FTP>login "anonymous" message saying guest login OK, asking you for your user name as password Password: your user name here (needn't be quoted) If all goes well, it should tell you that you are logged in; it will probably say that some access restrictions apply. In general, you will have to quote filenames or directories; you _probably_ don't have to quote commands (cd,get,dir,set,etc.). Hope this helps! -Max J ------------------------------ Date: 21 Jan 90 07:58:13 GMT From: tcr!gadgets!dsmall@boulder.colorado.edu (David M. Small ) Subject: Spectre 2.5 Newsletter advisory Message-ID: <3@gadgets.UUCP> Fairly soon, the next Gadgets by Small newsletter will be going out. If you haven't registered your Spectre 128 or GCR with us, now is the time; there's talk of even including a free 2.5 update with the newsletter (can't guarentee that, though). Still, it's fairly good stuff. If you have registered, our last newsletter went out last summer. If you missed it then, time to call and check. Or email me; this net address is unstable sometimes, I recommend the Well. (hplabs!well!dsmall, or dsmall@well.sf.ca.us). Details of some of the good things upcoming are within, and it's free, if you just let us know your address, to our owners that register. -- thanks, Dave / Gadgets by Small p.s. I mention this because many people feel registration cards are near worthless, and never hear anything from the companies that they send them into; we're not that way. So far, we've given two free software updates, three newsletters, and lots of good karma to people who've sent in their cards. . ------------------------------ Date: 22 Jan 90 22:53:18 GMT From: nsc!pyramid!infmx!robert@hplabs.hpl.hp.com (Robert Coleman) Subject: ST S/ware Rental Places Message-ID: <3165@infmx.UUCP> In article <25910@brunix.UUCP> rjd@cs.brown.edu (Rob Demillo) writes: >In article <1990Jan17.065533.601@murdoch.acc.Virginia.EDU> gl8f@astsun.astro.Virginia.EDU (Greg Lindahl) writes: >I agree completely. And don't believe I have insulted legitimate >businesses. If you want to see a piece of software run, go to >a store and ask the proprieter to start up a copy for you. I have >never been refused this request. > I basically agree with your other statements, but I just wanted to note that I *have* had requests to see software turned down in a number of stores- B&C Computervisions in Sunnyvale as an example. One of the reasons I don't shop there...I am lucky enough to have access to several stores in the area, but other users aren't as lucky. Under those circumstances, software rental places could serve a legitimate function. Robert C. -- "Helen's the only one who knows what scruples are, and she won't tell us" John said. "Have we got scruples about it, Helen?" "Not a trace," Helen affirmed. -The Reefs of Earth, R.A.Lafferty ------------------------------ Date: 19 Jan 90 07:37:34 GMT From: mcsun!hp4nl!tnosoes!joep@uunet.uu.net (Joep Mathijssen) Subject: TURBO-C Question! Message-ID: <671@tnosoes.UUCP> I'm trying to compile 'BISON' on my ST using the TURBO-C compiler. After a few changes the compilation was successful, but the linker still gives some weird errors. On standard C-function like 'free' I get: "16 bit PC relative overflow" When I change the order of the linked files, some other functions are listed. The linker is trying to call the function using relative addressing and sometimes the function is simply to far away. How can I solve this problem without changing compiler? Is there an option that I don't know. Or SHOULD I use another compiler? The only one I'm prepared to use is the GCC-compiler. But will this compiler work correct on an 1MB atari. Joep, =============================================================================== Joep Mathijssen TNO Institute for Perception P.O. Box 23 Phone : +31 34 63 562 11 3769 ZG Soesterberg E-mail: tnosoes!joep@mcvax.cwi.nl The Netherlands or: uunet!mcvax!tnosoes!joep =============================================================================== ------------------------------ End of INFO-ATARI16 Digest V90 Issue #83 ****************************************